I have published custom version of this package to nuget as NSubstituteNet6, it can be deprecated when the official package gets .NET 6 support https://www.nuget.org/packages/NSubstituteNet6/ it also fixes the security vulnerabilities mentioned here: #673

@Havunen Would it be possible to keep netstandard 1.3 for now to not cause breaking changes? As otherwise dependent libraries like "AutoFixture" would be broken 😢 We would most likely have to release a new major, but then it's a bit more changes and will take longer.

It would also help if you could drop a bit more info on reasoning of this PR (except you being generous and help to develop the project 😊). Is it blocking you in certain scenarios? This would also help to understand how soon it should be released.

Thank you!

Would it be possible to keep netstandard 1.3 for now to not cause breaking changes? As otherwise dependent libraries like "AutoFixture" would be broken 😢 We would most likely have to release a new major, but then it's a bit more changes and will take longer.

Ok, I can take a look.

It would also help if you could drop a bit more info on reasoning of this PR (except you being generous and help to develop the project 😊). Is it blocking you in certain scenarios? This would also help to understand how soon it should be released.

I was just trying to remove known security vulnerabilities from our project and then ended up here 😂

added back netstandard 1.3 target framework

@Havunen Thank you for your contribution!

I personally wouldn't update System.* packages unless they affect NSubstitute functionality, even if there are security fixes. NSubstitute is a library, I don't think it should drive the update process (vs a framework like ASP.NET or maybe xUnit). Anyway those libs can be updated directly, the NSub's version upper boundary is open. I can imagine cases when users just can't update those libs.

@alexandrnikitin ok I reverted that version upgrade, however it sucks big time to start installing dependencies of dependency at application level. Then one day the dependency refactors given dependency away and the application is still stuck with it, because nobody knows why it exists or why it was added and following these dependencies in each version upgrade is non trivial task in larger projects

Could this PR be merged and new version published to nuget?

@Havunen I understand your concerns regarding dependency management. It's a hard problem to crack and .NET world is not the worst compared to other ecosystems. I believe it should be on package manager's, IDE's or code analyzer's shoulders to solve it. AFAIK latest Visual Studio or R# can help with unused packages.

Merged. Thank you for the contribution and review discussion! 🙇

Any info when will this be published to nuget?

@aboryczko This has been published as 4.3.0. Sorry for the delay.

@dtchepak thanks :)